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EXECUTIVE  SUMMARY 


The  Reserve  Component  Automation  System  (RCAS)  and  Joint  Computer  Aided 
Ac((uisition  and  Logistics  System  (JCALS)  programs  are  large  Department  of  Defense 
(DoD)  initiatives  that  will  provide  automated  information  system  (AIS)  and  communications 
c^abilities  for  their  respective  conummities.  They  are  expected  to  realize  significant 
G^emment  cost  savings  and  avoidances.  This  report  documents  the  results  of  a  technical 
assessment  of  the  suitability  of  using  the  RCAS  and  JCALS  tystems  architectures  and  user 
i j^erface  methodologies  as  a  standard  in  other  DoD  functional  areas. 

The  RCAS  and  JCALS  system  architectures  were  determined  to  be  well-founded  and 
comprehensive  open  systems,  standards-based  architectural  models  that  are  compliant  with 
DoD  goals,  guidelines,  and  directives.  The  two  programs  have  several  architectural  and 
technological  similarities.  For  example,  diskless  X-Windows-based  terminals  are  slated  for 
use  as  the  primaiy  end  user  workstation,  and  similar  suites  of  office  automation  applications 
will  be  provided  for  both  programs.  Further,  POSlX-compliant  UNIX  operating  systems  will 
be  implemented  on  server  platforms  for  both  programs. 

Client-server  architecture-based  applications  will  be  implemented  for  both  programs  in 
various  forms.  Examples  include:  Ae  remote  presentation  client-server  model,  which  is  the 
foundation  fc.:  the  X-Windows-based  terminal  devices;  and  the  development  of  applications 
that  use  U  'X  pipes  or  sockets,  which  are  client-server-based  communications  processes. 
RCAS  and  JCALS  use  the  same  X-Window  System  and  OSF/MOTIF-based  graphical  user 
interface  (GUI).  The  GUI  is  an  integral  part  of  the  user’s  view  of  the  two  programs  and 
will  alleviate  the  need  for  each  user  to  become  proficient  in  the  use  of  the  operating 
systems. 

Both  program  tystem  architectures  are  designed  to  facilitate  interconnectivity  between  a 
large  number  of  remote  facilities.  Similarly,  the  two  programs  will  make  extensive  use  of 
LAN  technologies  at  the  program  sites.  The  RCAS  program  will  use  Ethernet-based  LANs, 
while  the  JCALS  program  will  implement  FDDI-based  LANs. 

While  the  RCAS  and  JCALS  programs  have  conceptual  similarities,  different  hardware  and 
software  platforms  and  products  have  been  selected  for  the  initial  implementation  of  each 
program. 

In  conclusion,  there  are  significant  features  provided  Ity  the  two  programs  that  may  be 
applicable  to  other  DoD  functional  areas.  The  open  systems,  standards-based  system 
architectures  of  the  two  programs  can  serve  as  models  for  ffiture  ^'stem  architectures.  The 
RCAS  program  includes  a  set  of  forms-based  Ada  applications  to  automate  the  completion 
and  processing  of  DoD  standard  forms.  Finally,  ^e  JCALS  program  is  developing  a 
sophisticated  Global  Data  Management  System  that  will  enable  JCALS  data  to  be 
implemented  in  physically  distributed  data  bases. 
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SECTION  1.  INTRODUCTION 


LI  Purpose  of  the  Technical  Report 

Hiis  report  assesses  the  suitability  of  using  the  Reserve  Component  Automation  System 
(RCAS)  and  Joint  Computer  Aided  Acquisition  and  Logistics  System  (JCALS)  systems 
architectures  and  user  interface  methodologies  as  a  standard  in  oAer  functional  areas.  It 
evaluates  the  programs.  This  report  was  developed  in  response  to  requests  from  the  Office 
of  the  Assistant  Secretary  of  Defense  (OASD)  for  Conunand,  Control,  Communications,  and 
Intelligence  (C^I). 

This  report  documents  the  methodology  used  in  evaluating  the  client-server  architectural 
and  user  interface  approaches  used  by  the  RCAS  and  JCALS  programs.  Additionally,  an 
analysis  of  the  RCAS  Economic  Analysis  Report  (EAR)  is  included. 

L2  Scope  of  the  Document 

The  sections  included  in  this  analysis  report  are  summarized  below: 

o  Section  1,  Introduction,  presents  the  purpose  of  the  report,  briefly  describes 
each  section  withm  the  document,  identifies  project  references  used  in  the 
preparation  of  this  report,  and  defines  terms  and  abbreviations  used 
throughout  the  document 

o  Section  2,  Background,  introduces  client-server  and  user  interface  technolo¬ 

gies,  and  discusses  the  hardware  and  software  components  and  communica¬ 
tion  technologies  available  from  the  RCAS  and  JCALS  programs. 

o  Section  3,  Evaluation  Methodology,  discusses  the  techniques  and  procedures 

used  in  evaluating  the  client-server  architectural  and  user  interface 
iq>proaches  employed  by  the  RCAS  and  JCALS  programs. 

o  Sections  4,  Conclusions,  summarizes  the  results  of  RCAS  and  JCALS  evalu¬ 

ation  efforts.  It  presents  conclusions  on  the  suitability  of  using  RCAS  as  a 
standard  for  client-server  architecture  and  user  interface  methodologies. 

o  Appendix  A,  RCAS  Compliance  with  the  DoD  Technical  Reference  Model 

(TRM)  Summary  Matrix,  depicts  the  capability  of  RCAS  to  satisfy  the 
provisions  of  the  DoD  TRM. 

o  ^>pendix  B,  RCAS  Compliance  with  the  DoD  Human  Computer  Interface 
(HQ)  Style  Guide  Summary  Matrix,  depicts  the  capability  of  RCAS  to 
satisfy  DoD  user  interface  methodology  requirements. 
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o  ^jpendix  C,  JCALS  Compliance  with  the  DoD  Technical  Reference  Model 
(TRM)  Summary  Matrix,  depicts  the  capabili^  of  JCALS  to  satisfy  the 
provisions  of  the  DoD  TRM. 

o  Appendix  D,  JCALS  Compliance  with  the  DoD  Human  Computer  Interface 

(HQ)  Style  Guide  Summary  Matrix,  depicts  the  capabilify  of  JCALS  to 
satisfy  DoD  user  interface  methodology  requirements. 

13  Project  Rgfcrencw 

The  following  documents  were  referenced  during  the  development  of  this  teclmical  rep« 

a.  Demonstration  of  the  Reserve  Component  Automation  System  (RCAS). 
The  Boeing  Company,  21  September  1992. 

b.  Human  Computer  Interface  Style  Guide.  Version  1.0.  Defense  Information 
Systems  Agency  (DISA)/Center  for  Infonnation  Management  (QM),  12 
February  1992. 

c.  MACQM  Validation  Review  of  RCAS  Economic  Analysis  Memorandum. 
Department  of  the  Army,  9  October  1991. 

d.  Reserve  Component  Automation  System  (RCASl  Hardware  Subsystem 
Specification.  Revision  A.  The  Boeing  Company,  19  June  1992. 

e.  Egsgrvs-CompoJicnt-AutQmatipn  System  (RCAS)  Systcifl-SpecificatioiL 
Revision  B.  The  Boeing  Company,  3  August  1992. 

f.  Reserve  Component  Automation  System  (RCAS)  Svstem/Subsystem  Sped- 
fication  Software  Subsystem  Specification.  Revision  B.  The  Boeing 
Company,  3  August  1992. 

g.  Reserve  Component  Automation  System  (RCAS)  Svstem/Subsvstem  Speci¬ 
fication  Telecommunication  Subsystem  Specification.  Revision  B.  The 
Boeing  Company,  1  April  1992. 

h.  Reserve  Component  Automation  System  (RCAS)  Technical  Analvsis/Cost 
Estimate  Technical  Report.  Final.  The  Boeing  Company,  7  February  1992. 

r.  Strategies  for  Open  Systems.  Defense  Management  Review,  1991. 

j.  Technical  Reference  Model  (TRM)  for  Infonnation  Management.  Version 
JL2»  Defense  Information  Systems  Agency  ^ISA)/Center  for  Information 
Management  (QM),  31  July  1992. 
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k.  Joint  Services/DI^  Computer  Aided  Acquisition  and  Logistic  Support 
(JCALS)  System.  Software  Requirements  Specification!  Book  1  -  Worksta¬ 
tion  Management  CSCIs  (1/4).  Computer  Sciences  Corooration,  31  March 
1992. 

l.  Joint  >Services/DLA  Computer  Aided  Acquisition  and  Lopstic  Support 
(JCALSl  System.  Software  Requirements  Specification.  Book  2  -  Network 
Management  CSCIs  ^2/5').  Computer  Sciences  Corporation,  31  March  1992. 

m.  Joint  Services /DLA  Computer  Aided  Acquisition  and  Logistic  Support 
(JCALS>  System.  Software  Requirements  Specification.  Book  3  -  Data 
Management  CSCIs  (3/6^.  Computer  Sciences  Corporation,  31  March  1992. 


n.  Army  Computer  Aided  Aci/uisition  and  Logistic  Support  (ACALS)  System 
BCM  Design  Finalization  Option.  Software  Deyelopment  Plan.  Computer 
Sciences  Corporation,  15  July  1992. 

o.  CALS  Human  Computer  Interface  fHCD  Style  Guide.  Computer  Sciences 
Corporation,  September  1992. 

1.4  Terms  and  Abbreviations 

The  terms  and  abbreviations  used  throughput  this  document  are  listed  below: 


ADP 

Automated  Data  Processing 

CAD 

Computer  Aided  Design 

OM 

Center  for  Information  Management 

CMW 

Compartmented  Mode  Workstation 

COTS 

Commercial  Off-the-Shelf 

C3I 

Command,  Control,  Communications,  and  Intelligence 

DCE 

Distributed  Computing  Environment 

DDBMS 

Distributed  Data  Jase  Management  System 

DEC 

Digital  Equipment  Coiporation 

DISA 

Defense  Mormation  Systems  Agency 

DOD 

Department  of  Defense 

GB 

Gigabyte 

GH 

Government-Furnished  Information 

GUI 

Graphical  User  Interface 

Ha 

Human  Computer  Interface 

HDS 

Human  Designed  Systems 

HQ 

Headquarters 

IBM 

International  Business  Machines 

ILS 

Integrated  Logistics  Support 

IWSDB 

Integrated  Weapons  Systems  Data  Base 
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JCALS 

Joint  Computer  Aided  Acquisition  and  Logistics  System 

KB 

Kilobyte 

LAN 

Local  Area  Network 

MB 

Megabyte 

MIS 

Management  Information  System 

MLS 

Multilevel  Security 

MMI 

Man-Machine  Interface 

NAVAB 

Navigation  Application  Broker 

NCC 

Network  Control  Center 

NCE 

Network  Computing  Environment 

OA 

Office  Automation 

OASD 

Office  of  the  Assistant  Secretary  of  Defense 

PC 

Persona]  Computer 

POSK 

Portable  Operating  System  Interface  for  Computer  Environment 

RAM 

Random  Access  Memory 

RCAS 

Reserve  Component  Automation  System 

RDBMS 

Relational  Data  Base  Management  System 

RISC 

Reduce  Instruction  Set  Computing 

ROM 

Read  Only  Memory 

SCO 

Santa  Cruz  Operation 

SQL 

Standard  Query  Language 

TOM 

Technical  Reference  Model 

VDT 

Video  Display  Terminal 

WAN 

Wide  Area  Network 

WOM 

Window  Object  Manager 

XDM 

X  Display  Manager 

SECTION  2.  BACKGROUND 


2.1  Client-Server  Concept 

As  described  in  the  DMR  document,  "Networking  Computing:  Strategies  for  Open  Sys¬ 
tems,”  the  TRM,  and  the  "DoD  Technical  Architecture  Framework  for  Information  Manage¬ 
ment”  clients  are  defined  as  hardware,  software,  persons,  or  a  combination  requesting 
services  from  servers.  Servers  are  defined  as  hardware,  software,  or  a  combination  providing 
resources  to  one  or  more  clients. 

The  client-server  model  is  described  as  cooperative  processing  where  an  entire  application 
is  divided  between  a  client  system  and  a  server  ^stem.  Both  client  and  server  components 
are  engaged  in  processing  die  application  such  that  the  software  component:  interact  to 
perform  Ae  function. 

To  describe  an  architecture  in  client-server  terminology,  the  hardware  and  software  compo¬ 
nents  of  the  system  must  be  defined  as  units  that  provide  services  to,  or  request  services 
from,  other  aTStem  components.  Figure  2-1  depicts  a  generic  client-server  model.  Both  the 
client  and  server  may  reside  on  the  same  hardware  platform  but  in  many  cases  are  on  sepa¬ 
rate  platforms.  The  critical  aspect  of  the  client-server  process  is  the  request/reply  inter¬ 
process  communication  between  client  and  server. 
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Figure  2-1.  Basic  Qient  -  Server  Model 
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Standards  are  a  cruc  ment  in  client-server  architectures  since  they  define  the  interface 
between  clients  and  servers.  The  standardization  of  these  interfaces  allows  client-server 
commurications  to  operate  effectively  in  an  open  systems  environment.  Two  major  architec¬ 
tural  standards  are  evolving  to  provide  guidelines  and  definitions  for  client-server  archi¬ 
tectures:  the  Open  Software  Foundation’s  (OSFs)  Distributed  Computing  Environment 
(DCE),  and  UNDC  International’s  (UI’s)  Open  Network  Computing  (ONC).  Further,  stan¬ 
dards  are  applied  in  virtually  all  areas  of  the  DoD  TRM  model  to  define  interfaces  between 
services. 

Ibe  fact  that  client-server  architectures  are  not  mature  must  be  considered  when  imple¬ 
menting  a  client-server  system.  Organizations  are  often  forced  tc  choose  among  proprietary 
approaches.  In  general,  the  recommended  approach  is  to  define  an  application  and  its  infor¬ 
mation  requirements  as  sets  of  generic  components  that  can  be  implemented  throughout  a 
network  computing  environment  (NCE).  This  results  in  defining  a  system  as  a  set  oi 
services  and  Ae  interfaces  between  these  services  and  components  that  require  their  use. 
An  emerging  standard  approach  is  to  separate  the  user  interface/application  code  and  have 
them  reside  on  a  workstation  while  the  data  bases,  triggers,  and  stored  procedures  reside 
on  servers.  Figure  2-2  illustrates  the  five  basic  client-server  models. 
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Figure  2-2.  Five  Basic  Client  -  Server  Models 
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The  cost  savings  of  implementing  a  client-server  architecture  will  be  realized  when  the 
mxhitecture  becomes  stable.  The  current,  conventional  application  environment  requires 
each  OCS  user,  for  example,  to  use  mainframe  CPU  cycles,  disk  queues,  and  RAM.  These 
same  operations  are  orders  of  magm'tude  cheaper  on  the  workstation.  Also,  existing  work¬ 
stations  that  ^ically  are  used  for  personal  productivity  applications  such  as  terminal 
emulation.  E-mail,  word  processing,  and  spreadsheet  work  may  be  used  for  mission-critical 
applications.  The  additional  functionality  of  the  client  portion  of  a  new  application  can  thus 
be  added  without  buying  a  new  workstation.  In  this  case,  the  cost  savings  of  offloading 
mainframe  processing  can  be  substantial.  If  client  and  server  functionality  are  clearly  split 
and  standards-based  access  is  used,  considerable  vendor  independence  may  exist  among 
application  components. 

Many  organizations  are  beginning  to  view  workstation  technology  as  a  commodity  and  select 
lower-priced  vendor  equipment.  Mainstream  vendors  have  realized  this  trend  and  are  mov¬ 
ing  to  provide  competitively  priced  client  workstations.  Each  mainstream  vendor  (e.g.,  IBM, 
Compaq,  Apple,  Sun,  Hewlett-Packard)  reduced  its  prices  by  at  least  33  percent  during  1991, 
prinuuily  in  response  to  an  erosion  of  market  share  for  client  workstations. 

The  client-server  paradigm  is  developing.  Standards  issues  that  must  be  decided  include  the 
use  of  RDA  as  a  standard  interface  to  an  SQL  data  base  engine,  the  use  of  RPCs,  and  the 
type  of  RPC  to  implement  (NCS  RPC,  Tl/RPC,  or  RPC  TOOL  or  some  other  RPC  imple¬ 
mentation).  The  initial  startup  costs  of  a  distributed  client-server  system  will  probably 
remain  hi^er  over  the  short  term  than  a  conventional,  non-client-server  system.  Over  time, 
as  these  systems  and  standards  stabilize,  significant  cost  savings  should  occur. 

22  User  Interface  Concent 

Today’s  emerging  graphical  user  interface  (GUI)  standard  is  the  (netwoi  k-aware)  X  Window 
System.  The  GUI  is  rapidly  becoming  an  integral  part  of  the  end  user’s  application  inter¬ 
face.  A  GUI  alleviates  the  need  for  each  user  to  become  proficient  in  the  use  of  the  oper¬ 
ating  system.  The  advantage  of  implementing  an  X  Windows  GUI  is  that  it  is  a  CIM  stan¬ 
dard  and  an  industry  standard  for  network-aware  GUIs. 

Using  an  X  Window  toolkit  such  as  MOTIF  insulates  the  user  from  the  technical  complexi¬ 
ties  of  the  operating  system,  and  provides  a  see-and-point  user  interface.  A  toolkit  allows 
developers  to  interface  vUth  the  X  Window  system  and  customize  the  end  user  displays  with¬ 
out  having  to  learn  X  lib  (low-level  X  Windows  routines)  commands  and  syntax,  lypicai 
implementations  of  a  toolkit  on  top  of  X  results  in  a  window  populated  with  icons.  Ihe 
icons  are  grphic  representations  of  applications  or  processes  that  can  be  selected  and 
invoked  with  a  mouse  button. 


X  Windows  can  be  displayed  on  any  hardware  device  that  supports  the  X  protocol.  A 
window  manager  provides  session  and  window  management  capabilities.  It  creates  the 
border  that  forms  around  every  window,  enabling  the  window  to  be  moved,  resized,  over¬ 
lapped,  shuffled,  and  reduced  to  an  icon  within  the  desktop. 

23  RCAS  Overview 

Tbe  RCAS  is  a  large  DoD  program  that  will  provide  automated  information  system  (ATS) 
and  communications  capabilities  to  hundreds  of  U.S.  Army  Reserve  and  Army  National 
Guard  Component  facilities.  The  equipment  and  services  provided  by  the  RCAS  will  signi¬ 
ficantly  enhance  command  and  staff  decision-making,  force  readiness,  and  mobilization 
planning  and  execution  activities.  The  program  is  expected  to  realize  significant  cost  savings 
and  avoidance. 

The  RCAS  Program  Management  Office  (PMO)  and  its  primary  contractor,  Boeing  Com¬ 
puter  Services  (BCS),  will  procure  and  implement  various  AIS  and  telecommunication 
^tem  configurations,  ranging  from  remote  stand-alone  workstations  or  terminal  devices 
with  a  dial-up  capability  to  large  complements  of  LAN-based  servers,  workstations, 
terminals,  peripherals,  and  telecommunications  equipment.  The  hardware,  software,  and 
telecommunications  system  components  are  described  in  the  following  subsections. 

2J.1  Hardware.  The  RCAS  will  consist  of  five  AIS  platforms:  X-stations,  workstations, 
office  automation  (OA)/terminal  servers,  electronic  mail  (E-mail)  servers,  and  application 
servers.  Figure  2-3  illustrates  the  interconnectivity  of  the  AIS  platforms  via  the  RCAS 
telecommunications  system  (TCS). 
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Figure  2-3.  RCAS  AIS  Interconnectivity 


The  AIS  platforms  are  described  below: 

o  X-stations:  High-resolution,  intelligent  terminal  devices  that  will  be  the 
primary  end  user  device  for  tihe  RCAS.  Four  types  or  models  will  be  imple¬ 
mented  for  the  RCAS  program.  Two  monochrome  (17-inch  and  19-inch) 
models  and  one  color  (14-inch)  model  will  be  employed  by  the  end  users. 
A  fourth  X-statioii  model  (19-inch  color)  will  be  used  with  the  network 
management  application  at  the  RCAS  Network  Control  Center  (NCC). 

o  Workstations:  Zenith  Data  Systems  486/33  Mhz  PCs,  used  in  lieu  of  X- 
stations  for  processor  and  memory-intensive  computer-aided  design  (CAD) 
and  graphic^  mapping  applications.  The  workstations  are  equipped  with 
19-inch  high-resolution  color  monitors,  32  MB  of  memory,  and  a  three- 
button  mouse.  They  support  the  same  man-machine  interface  (MMI)  as  the 
X-stations,  providing  consistency  across  hardware  platforms. 

o  Office  Automation/Terminal  Server:  A  Zenith  Data  System  486/33  Mhz 
computer  configured  with  24  to  64  MB  of  memory  and  peripherals.  Each 
OA  server  can  support  up  to  eight  concurrent  users  at  echelons  where  both 
the  office  automation  so^are  and  RCAS  applications /data  bases  reside  on 
the  OA  ser\*er.  The  OA  server  can  support  up  to  16  concurrent  users  at 
echelons  where  the  OA  server  only  supports  the  office  automation  software 
applications. 

0  E-Mail  Server:  The  E-mail  server  is  a  DEC  system  5500  configured  with 
256  MB  of  memory  and  5  or  10  GB  of  hard  disk  storage.  Mail  servers  are 
provided  at  each  wide  area  network  (WAN)  hub  to  accommodate  the  large 
WAN  transmissions  that  occur  during  mobilization.  The  mail  servers 
provide  mail  store-and-forward  services  for  the  RCAS  electronic  mail. 

o  Application  Server:  The  application  server  is  a  DEC  System  5000/200. 
DEC  System  5500  computers  are  used  for  the  RCAS  application/data  base 
servers.  The  DEC  system  5000/200  is  configured  with  128  MB  of  memory 
and  2  to  4  GB  of  hard  disk  storage.  The  DEC  System  5500  is  configured 
with  256  MB  of  memory  and  2  to  10  GB  of  hard  disk  storage.  This  server 
employs  a  DEC  Reduced  Instruction  Set  Computing  (RISC)-based  proces¬ 
sor,  which  hosts  the  applications  and  data  base  processes,  improving 
performance  and  response  time. 

23Ji  Software.  The  RCAS  progr^  includes  sets  or  suites  of  standard  software  products 
to  be  used  with  the  five  AIS  platforms.  The  software  suites  are  defined  in  terms  of  three 
functional  areas  or  groups:  OA,  support  software,  and  application  software.  Table  2-1 
presents  the  three  software  groups  and  the  components  or  applications  associated  with  each 
group.  The  table  also  depicts  the  appropriate  AIS  platforms  Aat  house  the  software  groups. 


Table  2-1.  RCAS  Software  Environment 


SOFTtVARE  GRCUS* 

$(^YARE  COMPONENTS 
(APPUCAIIONS) 

AtS  PUTFORM 

Office  Automation 

Word  Processing 

Spreadsheet 

Bectronic  Mail 

Desktop  Organizer 

Persona]  DBMS 

Presentation  Graphics 

Project  Manager 

Desktop  Publisher 

OA  Sen/er,  Workstation 

Support 

Operating  System 

Administration  Tools 

Graphical  User  Interface 

Secure  Communications 

DBMS 

Text  Retrieval 

Bar  Code  Printing 

CAD/CAM 

Map  Graphics 

CBT 

OCR 

Linear  Programming 

OA  Server,  Combined 

OA/Application  Sewer 

NOTE:  The  three  sewers  and  the 

workstation  platforms  are 
configured  with  operating 
system,  system  administra¬ 
tion,  GUI,  and  communica¬ 
tions  software. 

Application 

Mobilization  Command  and  Control 
Aviation  Operations 

Force  Authorizations 

Human  Resources 

Training 

Resource  Management 

Ljogistics 

International  Facilities 

Safety 

Information 

Internal  Review  Program 

Applicatio'i,  Combined 

OA/Appllcation  Sewers 

A  fundamental  design  objective  for  the  RCAS  program  was  to  achieve  "immediate  usability 
and  mission  acceptance.”  To  accomplish  this  goal,  a  consistent,  user-friendly  MMI  is 
required.  The  suite  of  software  products  selected  for  the  RCAS  meet  this  requirement  and 
provide  a  standard  look  and  feel  MMI.  Specific  examples  are  presented  below; 

o  Each  OA  server  platform  runs  under  the  Santa  Cruz  Operation  (SCO) 
CMW+  operating  system  environment.  Therefore,  every  RCAS  user  will 
be  provided  a  common  GUI  and  MMI,  At  small  sites,  the  OA  and  applica¬ 
tion  server  software  suites  will  be  housed  in  a  single  server  platform.  At 
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larger  sites,  the  server  software  suites  will  be  housed  on  separate  server 
platforms. 

o  The  E-mail  servers  will  run  the  DEC  ULTRIX  MLS+  operating  system, 
providing  mail  store-and-forward  services  to  RCAS  users. 

o  The  X-station  models  contain  minimal  software  in  onboard  Read  Only 
Memory  (ROM),  and  rely  on  downloading  the  X-server  software  and  sup¬ 
porting  configuration  parameters  from  the  host  (i.e..  Zenith  486  OA  server 
running  CMW+ /386).  When  the  X-station  is  powered  on,  it  sends  a  broad¬ 
cast  message  expecting  a  response  from  a  CMW  host.  The  host  that  has 
the  X-station  configured  in  its  tables  will  return  an  address  to  the  X-station. 
The  X-station  can  then  establish  communications  with  the  host  and  down¬ 
load  its  configuration  file,  X-server,  and  fonts.  When  the  X-station  has 
completed  its  configuration,  the  X  Display  Manager  (XDM)  on  the  CMW 
host  downloads  the  login  screen,  which  is  displayed  on  the  X-station  by  the 
trusted  X-server.  XDM  manages  the  login  screen  to  ensure  that  the  trusted 
path  is  active  between  the  X-station  and  CMW  host.  The  GUI  promotes 
ease  of  use  for  all  levels  of  users,  from  inexperienced  to  very  experienced, 
reducing  the  amount  of  training  time  required. 

2  J J  Communications.  In  addition  to  providing  the  information  processing  platforms 

described  in  the  previous  subsections,  the  RCAS  program  includes  a  telecommunications 
^tem  to  address  the  connectivity  requirements  of  the  various  end  users.  The  TCS  will 
enable  connectivity  between  RCAS  end  systems  and  user  terminal  devices  via  a  dedicated 
router-based  WAN.  The  WAN  will  link  many  LANs,  and  will  support  connectivity  for  dial¬ 
up  access  and  gateway  connections  to  exter^  networks.  The  TCS  will  support  both  the 
GOSIP  and  DDN  protocol  stacks,  and  will  provide  the  following  services: 

o  T'ansaction  processing  (application-to-application) 

o  File  services  (access,  transfer,  and  management) 

o  E-mail  (X.400  mail  service)  _ 

o  Remote  batch  (remote  job  submission) 

0  Interactive  (access  to  RCAS  application  processors) 
o  Network  management  (system  operations  centers). 

The  WAN  is  based  on  a  three-tiered  architecture.  The  first  tier  (Level  1)  consists  of  five 
backbone  router  nodes  connected  in  a  full  mesh  configuration.  The  second  tier  (Level  2) 
consists  of  regional  nodes  generally  located  at  State  Area  Reserve  Centers  (STARCs).  The 
Level  2  nodes  act  as  hubs  for  lower  echelon  dedicated  circuits  in  their  area.  The  thfrd  tier 
(Level  3)  nodes  are  dedicated  access  nodes  that  typically  have  a  single  connection  to  the 
RCAS  TCS  network.  Finally,  small  non-LAN-based  sites  are  connected  to  the  TCS  via  dial¬ 
up  XJ25  circuits. 
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National  Security  Agency  (NSA)-approved  end-to-end  network  encryption  devices  will  be 
implemented  for  LAN-based  traffic,  and  STU-in  link  encryption  devices  will  be  used  to 
provide  security  for  the  dial-up  circuits. 

Finally,  the  RCAS  TCS  also  includes  network  management  capabilities  implemented  via  a 
complement  of  hardware  and  software  products  that  will  be  housed  in  a  primary  and 
secondary  Systems  Operations  Center  (SOC). 

2.4  JCALS  Overview 

The  JCALS  effort  is  the  result  of  previous  logistic  endeavors  to  combine  the  direction  and 
resources  of  Service-specific  logistics  systems  to  provide  a  standard  unified  logistics  system 
usable  across  all  Services  and  the  Defense  Logistics  Agency  (DLA).  The  entities  that 
precede  JCALS  include  Army  CALS,  DLA  CALS,  Air  Force  CALS,  Marine  Corps  CALS, 
and  Navy  CALS.  Each  has  several  goals  or  objectives  toward  proriding  logistics  to  their 
respective  Service  or  agency. 

Army  CALS  objectives  were  to  provide  logistic  information  sharing  among  various  users; 
provide  a  common  and  integrated  structure  for  organizing  data;  provide  an  interface  among 
government  end  users,  government  agencies,  and  concerned  industries;  implement  DoD-wide 
standards  for  logistics  and  technical  information;  provide  uniform  ILS  and  reliability, 
availability,  and  maintainability  tools  for  weapon  system  developers;  and  provide  a  flexible 
architecture  that  can  grow  into  the  next  century. 

DIA  CALS  was  the  combination  of  CTOL,  EDMICS,  MEDALS,  MPCASS,  DRAMA, 
DUS,  and  ITAP.  The  curreiit  and  plaimed  functions  of  these  systems  include  cataloging 
new  itenr;  entering  the  supplyjsystem,  automating  DLA  repositories  and  technical  libraries, 
indexing  u  chnical  data  elements,  identifying  specific  DoD  repository  locations,  automating 
the  interface  between  contractors  and  the  military  parts  control  advisory  group,  and 
enhancing  the  validation  of  supply  requests. 

Air  Force  CALS  has  had  a  vision  cf  intercormecting  the  seven  current  tystems  that  provide 
logistic  information  within  that  Service.  Their  vision  of  interconnection  would  consist  of 
installing  communications  gateways,  networks  (both  local  area  and  wide  area),  and  interfaces 
and  translators,  and  cormecting  functional  workstations  and  processors  to  provide  access  to 
logistics  information. 

Marine  Corps  CALS  was  a  combination  of  many  entities,  including  the  Logistics  Information 
Systems  Branch;  the  Marine  Corps  Logistics  Base;  the  Marine  Corps  Research,  Develop¬ 
ment,  and  Acquisition  Command;  and  the  USMC  Combat  Development  Command. 

Navy  CALS  was  identified  as  a  consortium  of  information  based  on  Navy  Items  of 
Automation  (lOAs). 
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On  11  January  1991,  the  Major  Automated  System  Information  Review  Committee  issued 
a  System  Decision  Memorandum  that  directed  PM  Army  CALS  to  incorporate  minimum 
essential  requirements  of  the  Air  Force,  Navy,  Marine  Corps,  and  DLA  into  the  Army 
CALS  program.  On  4  October  1991,  the  Assistant  Secretary  of  Defense  for  Production  and 
Logistics  issued  a  memorandum  establishing  the  JCALS  program  as  a  Joint  Defense  pro¬ 
gram. 

2.4.1  Hardware.  JCALS  consists  of  six  hardware  groups:  data  management  processors 
(DMPs),  workstation  servers,  workstations,  input  devices,  output  devices,  and  storage 
devices.  The  hardware  groups  are  highlighted  below: 

o  Data  management  processors.  The  DMPs  can  be  viewed  as  a  single 
processor  with  the  capability  of  accessing  remote  data  management  systems 
through  the  use  of  software  and  communications  subsystems.  The  DMPs 
will  be  capable  of  supporting  an  ANSI  X3.135  SQL-compliant  relational 
data  base  management  system  (RDBMS).  The  RDBMS  is  a  multilevel 
secure,  commercial  off-the-shelf  relational  DBMS  that  can  access  distribut¬ 
ed  JCALS  data.  This  secure  DBMS,  currently  INFORMIX,  is  coupled  with 
the  Global  Data  Management  System  (GDMS),  which  provides  the  access 
to  data  distributed  across  the  Integrated  Weapons  Systems  Data  Base 
(TWSDB),  to  provide  all  data  access  within  the  distributed  environment. 
The  secure  DBMS  runs  under  a  B  1-rated  UNIX  operating  system  and  is 
designed  to  meet  the  B1  Trusted  Computer  Security  that  provides  the 
capability  to  store  classified  and  unclassified  data.  In  addition,  a  COTS  text 
DBMS,  currently  BASISPLUS,  is  used  to  access  SGML  tagged  information. 

o  Workstation  servers.  The  workstation  server  will  support  a  POSIX- 
compliant  operating  system  and  provide  a  work  group-level  storage,  data 
management,  printing,  and  communications  capability.  The  workstation 
server  will  also  support  transparent  remote  data  access;  digitization;  and 
compression  of  input  data,  raster  and  vector  graphics,  and  optical  media. 
The  workstation  server  will  be  able  to  receive  and  route  data  fi’om  local 
workstations  to  remote  workstations  and  peripherals. 

o  Workstations.  JCALS  will  support  three  types  of  workstations: 

A  CAD/CAE  workstation  for  CAD/CAE  functions  as  well  as  US/ 
RAM  workbench  activities 

A  color  user  workstation,  which  supports  users  requiring  color 
graphics  and  limited  ILS/RAM  workbench  activities 

A  user  workstation,  which  provides  access  to  resources  on  the  work¬ 
station  server. 
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o  Input  devices.  Input  devices  include  scanners,  punch  card  readers,  and 
Microfiche  readers. 

o  Output  devices.  Output  devices  include  printers,  plotters,  and  high- 
resolution  color  and  CAD/CAE  monitors. 

o  Storage  devices.  As  a  result  of  the  differing  requirements  for  storage 
media,  the  following  storage  devices  are  supported  by  JCALS: 

DMP  disk 

Workstation  server  disk 
-  CAD/CAE  workstation  disk 
Optical  disk  jukebox 
Optical  disk  drive 
Helical  scan  tape  drive 
9-track  tape  drive. 

2.42  Software.  The  JCALS  program  includes  sets  or  suites  of  standard  software 
products  to  be  used  with  the  AIS  platforms.  The  software  suites  are  defined  in  terms  of 
three  functional  groups:  workstation,  network  management,  and  data  management  software. 
Table  2-2  presents  the  components  of  the  three  software  groups  and  vendcr/product  infor¬ 
mation  for  the  appropriate  software  component 

A  fundamental  design  objective  of  the  JCALS  program  was  to  achieve  "immediate  usability 
and  mission  acceptance."  To  accomplish  this  goal,  a  consistent,  user-friendly  MMI  is 
required.  The  suite  of  software  products  selected  for  the  JCALS  meet  this  requirement  and 
provide  a  standard  look  and  feel  MMI.  The  JCALS  human-computer  interface  will  consist 
of  Xll  and  OSF/MOTIF  1.1  as  a  base  from  which  to  expand.  MOTIF  will  provide  the 
Took  and  feel"  of  the  application.  On  the  other  hand,  Xll  will  provide  support  for  user 
interactioiL  MOTIF  will  provide  a  presentation  User  Interface  I^guage  (UIL)  that  will 
describe  the  visual  aspects  of  the  user  interface  in  text  format  in  a  file.  A  window  manager 
also  will  be  provided  to  manage  the  operation  of  all  windows  on  the  end  user’s  screen. 

The  JCALS  ^tem  will  enable  the  end  user  to  provide  user  interfacing  by  several  different 
methods:  direct  manipulation,  object-action  selection,  menu  selection,  text  entry,  and  a 
cotmnand  language.  Each  method  will  provide  the  user  with  ample  opportunities  to  interact 
with  the  JCALS  system  in  an  efficient,  user-friendly,  easy-to-leam  meffiod,  and  will  provide 
tools  for  the  more  experienced  end  user. 

2.43  Communications.  The  network  architecture  is  organized  into  the  three  tiers  shown 
in  figure  2-4.  Tier  1  is  the  Regional  Servi<»  Center  Tier.  This  tier  is  the  System 
Operational  and  Support  Capacity  (SOSC).  The  purpose  of  the  SOSC  is  to  monitor  and 
et^uate  the  performance  of  the  JCALS  network.  When  issues  with  the  network  exist,  the 
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Table  2-2.  JCALS  Software  Environment 


■EgSSBSail 

aOFTWAPE  Cbrtl»C«EKI 

Workstation 

Oparation  System 

DEC  ULTRIX  MLS-f 

Oasktop  Manager 

DaXDesktop 

Online  Help 

DOXDeskhelp 

Office  Automation 

Applix  Asterix 

Lowr-End  Bectronic  Publishing 

Arbortext  SGML  Publisher 

Arbortext  Island  Paint 

Arbortext  Wand  Draw 

Arbortext  CALS  Filters 

SGML  Editor 

Arbortext  SGML  Editor 

lasOA  Read/Wffie  Utilities 

krfodeslgn  1840A  Read/Write  Utilities 

SGML  Auto-Tagger 

Avalanche  FastTag 

Intaractiva  Technical  Manual  Browser 

Excalibur  EFS 

Technical  llustrator 

Autotrol  Tl  Plus  with  Raster 

Autotrot  S5000  Md 

Autotrol  SOL 

Autotrol  Postscript 

Drawing  Mewar/Redliner 

Rosetta  Prepare 

Rosetta  Preview 

ILT/RAM  Tools 

ISSSUC 

ISSFMECA 

ISSLORA 

ISSLSC 

MSI  Predictor 

MSI  C-Maintainability 

MSI  Results 

MSI  Reality 

MSI  FRACAS 

Vlawlogie  Workview  Series  II  with  VHOL  Package 

MSI  Block  Diagram  Evaluator 

Low-End  CAD 

Autodesk  Autocad 

Concurrent  Engineering 

Aries  DXF  Pre/Post 

Aries  Concept  Solids 

Aries  Concept  Mass 

Aries  Concept  Materials 

Aries  Printer  Support 

Projact  Management 

Productivity  Solutions  Ultra  Planner 

Telaconferertcing 

Saratoga  Information  Systems  XPCS 

NatvMxfc  Managamont 

Operating  System 

DEC  ULTRIX  MLS-f 

Communications 

System  Strategies  Easy  Bridge 

SNA/3ZT0 

Advanced  Communications 

Concepts  ACP  32S0 

Advanced  Communications 

Concepts  OSI 

Communications  Management 

DEC  Management  Station  for  ULTRIX 

Data  Manaeamant 

Operating  System 

DEC  ULTRIX  MLS-f 

Data  Baaa  Management  System 

Sybase  Secure  Server 

Text  Data  Base  Management  System 

Information  Dimensions  Basis  Plus 

Multiple  Data  Base  Interface 

Sybase  Open  Host  Server  Information  Builders 
EOASQL 

Jukebox  Interface 

0-Slar  Optical  Disk  Jukebox  Software 
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Figure  2-4.  Tiered  Network  Architecture 


responsibiliQr  of  SOSC  is  shifted  from  monitoring  to  problem-solving.  SOSC  logs  all  issues 
and  either  takes  corrective  action  or  contacts  the  local  sites  so  that  action  can  be  taken. 
SOSC  also  performs  network  management  and  network  security. 

Her  2  is  the  Organization  Tier  and  is  composed  of  three  components.  The  first  component 
is  the  Workstation  Server,  which  is  used  to  connect  the  workstations  to  the  rest  of  the 
network.  The  second  component  is  the  Network  Processor,  which  is  used  to  control  and  link 
the  local  site  network  to  the  WAN.  The  last  component  is  the  Data  Management  Processor, 
which  is  used  to  collect  network  statistics  at  each  site  and  relay  this  information  back  to  the 
SOSC 

Tier  3  is  the  User  Tier.  This  tier  also  consists  of  three  components:  user  workstations, 
color  user  workstations,  and  CAD/computer-aided  engineering  (CAE)  workstations.  Tier 
3  is  basically  software  and  hardware  used  at  the  user  level  to  comect,  retrieve,  and  process 
information  off  the  network.  | 

2^.4  Site  Overview.  Tier  1  (SOSC)  is  the  overall  monitoring  and  control  center.  Tiers 
2  and  3  describe  the  .sites  that  Tier  1  is  supporting.  A  typical  Ti^  2/Tier  3  site  consists  of 
four  subsystems:  \ 

o  Network  Management 

o  Data  Management 

o  Workstation 

o  Network  Distribution. 
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Each  site  uses  the  four  subsystems  to  communicate.  The  Network  Management  Subsystem 
perfonns  the  communications  between  the  sites  using  a  WAN.  The  Network  Management 
Subsystem  also  links  the  network  with  the  existing  systems.  The  Network  Management 
Subsystem  (JCALS  network)  and  the  existing  ^tems  communicate  through  connectivity 
provided  by  IEEE  8023. 

The  Data  Management  Subsystem  is  responsible  for  administration,  updating,  and  control 
acceiis.  Further  responsibilities  are  to  route  and  maintain  the  status  of  user  queries  and 
responses. 

The  Workstation  Subsystem  provides  users  with  software  and  h  .  ware  that  will  enable 
them  <.o  communicate,  use  office  automation,  and  perform  engineering  functions  and  G\D. 

The  Network  Distribution  Subsystem  provides  system  interfacing  within  the  site. 

The  JCALS  network  is  shown  in  figure  2-5.  This  figure  shows  the  LANs  and  the  structure 
described  above,  and  its  also  shows  how  the  LANs  are  tied  together  using  the  WAN  and  the 

sosc.  ! 


LEGBID 


□  WORKSTATION 


-  •02.SLAN 

0  DATA 

MANAGEMENT 

PROCESSOR 


liiil  EXISTING  SYSTEMS 
PROCESSOR 


WORKSTATION 

SERVER 


H  NETWORK 
PROCESSOR 


Figure  2-5.  JCALS  Network 


SECTION  3.  EVALUATION  METHODOLOGY 


3.1  Evaloat!on  Methodology  Overview 

This  section  presents  the  techniques  and  procedures  used  in  evaluating  the  RCAS  and 
JCALS  programs.  The  RCAS  evaluation  process  consisted  of  an  analysis  of  the  RCAS  sys¬ 
tems  architecture  with  respect  to  client-server  technology  and  user  interface  methodology, 
and  an  economic  analysis  of  the  RCAS  program  to  determine  the  suitability  of  applying 
these  methodologies  and  approaches  to  other  DoD  functional  areas. 

32  RCAS  Evaluation  Methodoloav 

The  RCAS  evaluation  process  consisted  primarily  of  a  review  and  analysis  of  the  related 
RCAS  system  documentation  listed  in  section  13  of  this  report.  To  augment  this  process, 
evaluation  team  members  attended  software  demonstrations  designed  to  demonstrate  the 
functional  capabilities  of  RCAS.  These  software  demonstrations  were  presented  by  one  of 
the  primary  RCAS  software  vendors  (UNIPLEX)  and  the  RCAS  system  developers  located 
at  the  RCAS  PMO  demonstration  facility. 

For  clarity,  the  activities  conducted  during  the  RCAS  evaluation  are  summarized  in  table 
3-1.  This  table  identifies  the  evaluation  stages,  activity  performed  during  the  stage,  and  the 
section  in  this  report  where  the  activity  is  described  in  detail  and  where  the  associated 
results  are  provided. 


Table  3-1.  RCAS  Evaluation  Methodology  Summary  Matrix 


STAsm 

ev«mTioitACTivnv 

1 

OtMlop  a  formal  dafinition  for  eliant.aarvar  arehitaetura 

Saction3Z.1 

Sactton  4.1.1 

2 

Evahiata  RCAS  to  Marrtity  dlam-aatvar  modala  avallabla 
from  RCAS  hardwata  and  aoftwara  oomporranta 

Saclion3Z.1 

Sactlon  4.1.1 

3 

AaiiH  oompHanoa  of  hatdwara/aoftwara  oomporrantt  utad 
for  oRant-aarvar  modala  wHti  OoD  TRM 

Saction  3.2.1 

Appandix  A 

4 

Aaaaaa  RCAS  hardwara  and  aoflwaia  componam  eompil* 
anoa  wHh  DoO  HC>  Siyla  Gulda 

Saolion3.2Z 

Appendix  B 

5 

CotMhJOt  RCAS  Eoonomlo  Analyaia 

Sactlon  3.2.3 

Sactlon  4.U 

6 

AOand  aoftwara  damonatrationa  to  valldata  findinga  raautl- 
big  ffom  avaluation  of  RCAS  program 

Sacliona  3Z.1, 3ZZ,  3Z.3 

Appendix  A  and  B 

7 

Dooumant  raaulta  and  davatop  oondualona 

Sactiona  3.2.1, 3.2.2, 3.2.3 

Sactton  4  and  all 
appandixaa 

32.1  qient-Server  Evaltiatlon  Methodolo^.  To  support  the  client-server  evaluation 
process,  the  following  methodology  was  implemented: 

o  Reference  Stage  1.  An  operational  definition  of  the  client-server  model(s) 
was  abstracted  from  information  contained  in  three  reference  documents: 
Chapter  10  of  the  Defense  Management  Review  (DMR),  "Strategies  for 
Open  Systems";  Volume  2  of  the  "DoD  Technical  Architecture  Framework 
for  Information  Management";  and  Version  13  of  the  DISA  Center  for 
Information  Management  "Technical  Reference  Model  for  Information 
Management." 

o  Reference  Stage  2.  The  RCAS  systems  architecture  and  AIS  platforms 
were  evaluated  with  respect  to  the  derived  client-server  architecture  defini- 
tioa  The  evaluation  was  based  on  a  review  of  the  RCAS  Systems  Specifi¬ 
cation  and  the  Software,  Hardware,  and  Telecommunications  Subsystems 
Specification  documents. 

o  Reference  Stage  3.  The  DISA  Center  for  Information  Management  "Tech¬ 
nical  Reference  Model  for  Information  Management"  document  was 
reviewed  and  applicable  standards  were  extracted  and  included  in  a 
compliance  matrix  checklist.  Chapter  10  of  the  DMR,  'Strategies  for  Open 
Systems,"  references  the  OSF  DCE  as  a  standard  to  be  used  for  evaluating 
client-server  architectures.  However,  in  the  DoD  community,  the  OSF 
DCE  standard  is  represented  by  the  DoD  TRM.  Therefore,  the  DoD  TRM 
was  used  in  evaluating  the  RCAS  program. 

o  Reference  Stage  6.  Software  demonstrations  of  the  software  component 
UNIPLEX  and  the  RCAS  program  were  attended  on  17  and  21  September 
1992,  respectively.  The  demonstrations  were  used  to  verify  information 
obtained  through  review  of  RCAS  system  documentation  and  to  assist 
completion  of  the  DoD  TRM  matrix  provided  in  appendix  A. 

o  Reference  Stage  7.  The  results  of  each  stage  of  the  evaluation  are 
documented  in  the  appendixes  of  this  document 

322  User  Interface  Evaluation  Methodology.  To  support  the  user  interface  evaluation 
process,  the  following  methodology  was  implemented: 

o  Reference  Stage  4.  The  DoD  "Human  Computer  Interface  (HCI)  Style 
Guide"  was  reviewed  and  user  interface  requirements  were  developed. 
These  requirements  were  documented  in  a  DoD  HCI  Style  Guide  compli¬ 
ance  matrix  (see  appendix  B).  A  thorough  and  comprehensive  analysis  of 
RCAS  user  interface  documents  was  then  conducted  to  assess  RCAS 
compliance  with  the  requirements  documented  in  the  compliance  matrix. 
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o  Reference  Stage  6.  Software  demonstrations  of  the  software  component 
UNIPLEX  and  the  RCAS  program  were  attended  on  17  and  21  September 
1992,  respectively.  The  demonstrations  were  used  to  verify  information 
obtained  through  review  of  RCAS  user  interface  documentation  and  to 
assist  completion  of  the  DoD  HCI  Style  Guide  compliance  matrix  provided 
in  appendix  B. 

o  Reference  Stage  7.  The  results  of  each  stage  of  the  evaluation  were 
documented  and  are  included  in  the  appendixes  of  this  document. 

Technical  Economic  Analysis  Evaluation.  To  support  an  economic  analysis  of  the 
RCAS  program,  a  benefit  analysis  was  conducted  using  the  following  methodology: 

o  Reference  Stage  5.  The  RCAS  Benefits  Analysis  (BA)  is  based  on  the 
functionality  of  RCAS  and  the  Milestone  1  BA  From  these,  the  following 
candidate  tangible  benefits  were  identified: 

Man-hours  avoided  by  automation  in  completing,  staffing/approving, 
or  hand-carrying  a  form  during  distribution.  (Cost  avoidance) 

•  Long-distance  telephone  calls  saved  through  automation.  (Cost 
savings) 

•  Reproduction  (Xeroxing)  of  forms  saved  through  automation.  (Cost 
savings) 

.  Transmission  of  forms  saved  through  automation  (transmission  of 
forms  currently  occurs  through  vehicles  such  as  facsimile  (FAX), 
overnight  mail  delivery,  and  regular  mail  delivery).  (Cost  savings) 

From  the  above  candidates,  a  total  of  $3.2  billion  in  constant  FY  91  dollars  or  $5.1  billion 
in  inflated  dollars  during  the  period  of  FY  92  through  FY  02  in  tangible  savings  was  pro¬ 
jected  over  the  expected  life  of  the  RCAS  system. 

The  RCAS  Functional  Description  (FD)  defines  the  specific  actions  required  to  be  per¬ 
formed  at  the  designated  echelons  and  generates  the  requirements  for  automation  support. 
Tire  level  at  which  these  processes  occur  is  critical  to  the  design  of  the  requirements. 

Projected  benefits  were  quantified  from  two  groups  of  information: 

o  The  amoimt  of  resources  spent  completing  administrative  processing 
through  current  procedures 


3-3 


0  The  amount  of  current  resources  that  the  Reserve  Component  will  save/ 
avoid  as  a  result  of  the  RCAS. 

The  first  group  was  collected  primarily  via  mailed  questionnaires  from  randomly  selected 
units  representing  the  population  of  prospective  RCAS  users.  Approximately  800  question¬ 
naires  were  mailed,  resulting  in  over  250  responses.  Additionally,  analysts  visited  units  in 
Georgia  and  Texas,  collecting  data  through  on-site  interviews. 

The  second  group  was  derived  through  FD  review  and  Competitive  Demonstration  observa¬ 
tion,  and  provided  the  basis  for  estimating  RCAS  efficiencies. 

JCALS  Evaloation  Methodology 

The  JCALS  evaluation  process  consisted  of  an  analysis  of  the  JCALS  systems  architecture 
with  respect  to  client-server  technology,  and  user  interface  methodology  to  determine  the 
suitability  of  applying  these  methodologies  and  approaches  to  other  DoD  functional  areas. 

The  JCALS  evaluation  process  consisted  primarily  of  a  review  and  analysis  of  the  related 
JCALS  system  documentation  listed  in  section  13  of  this  report.  To  augment  this  process, 
evaluation  team  members  attended  software  demonstrations  designed  to  demonstrate  the 
functional  capabilities  of  JCALS.  These  software  demonstrations  were  presented  by  JCALS 
^tem  developers. 

For  clarity,  the  activities  conducted  during  the  JCALS  evaluation  are  summarized  in  table 
3-2.  This  table  identifies  the  evaluation  stages,  activity  performed  during  the  stage,  and  the 
section  in  this  report  where  the  activity  is  described  in  detail  and  where  the  associated 
results  are  provided. 


Table  3-2.  JCALS  Evaluation  Methodology  Summaiy  Matrix 


CVAtUATKWACniVnV 

DETAUJEO  DISCUSSION 

NESULTO 

1 

Oavatop  a  formal  eaflnftion  for  cHant-aarvar  architactura 

Saction  3.3.1 

Section  4Z.1 

2 

Evaluata  JCALS  to  ktantify  dlant-aarvar  modalt  availabla 
from  JCALS  hardwara  and  aoftwara  oomponanta 

Saction  3.3.1 

Saction  4Z.1 

3 

Aaaaaa  oompllanca  of  hardwara/aoftwara  eomportanta 
uaad  tor  cHant-aarvar  modala  with  OoD  TRM 

Saction  3.3.1 

Appendix  C 

4 

Aaaaaa  JCALS  hardwara  and  aoftwara  oomponant  eompli- 
anoa  wfth  OoD  HCI  Stylo  Gulda 

Sactton  3.3Z 

Appendix  0 

S 

Attond  aoftwara  damonatratlona  to  validata  findinga  raault- 
Ing  from  ovaluation  of  JCALS  program 

Sactiona  3.3.1, 34.2, 

3.3J 

Appendix  C  and  D 

6 

Dooumant  raauKa  end  davatop  oonduaiona 

Sactiona  3.3.1, 3.3Z, 

3.3.3 

Soctkhi  4  and  aii 
appondixea 

/  ,  '■ 
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33.1  Client-Server  Evaluation  Methodology.  To  support  the  client-server  evaluation 
process,  the  following  methodology  was  implemented: 

o  Reference  Stage  1.  An  operational  definition  of  the  client-server  model(s) 
was  derived  from  information  contained  in  three  reference  documents: 
Chapter  10  of  the  DMR,  "Strategies  for  Open  Systems";  Volume  2  of  the 
"DoD  Technical  Architecture  Framework  for  Information  Management"; 
and  Version  13  of  the  DISA  Center  for  Information  Management  "Tech¬ 
nical  Reference  Model  for  Information  Management" 

o  Reference  Stage  2.  The  JCALS  ^tems  architecture  and  AIS  platforms 
were  evaluated  with  respect  to  the  deiived  client-server  architecture  defini¬ 
tion.  The  evaluation  was  based  on  a  review  of  the  JCALS  Systems  Specifi¬ 
cation,  and  the  Sc>ftware,  Hardware,  and  Telecommunications  Subsystems 
Specification  documents. 

o  Reference  Stage  3.  The  DISA  Center  for  Information  Management 
"Technical  Reference  Model  for  Information  Management"  document  was 
reviewed,  and  applicable  standards  were  extracted  and  included  in  a 
compliance  matrix  checklist.  Chapter  10  of  the  DMR,  "Strategies  for  Open 
Systems,"  references  the  OSF  DCE  as  a  standard  to  be  used  for  evaluating 
cUent-server  architectures.  However,  in  the  DoD  community,  the  OSF 
DCE  standard  is  represented  by  the  DoD  TRM.  Therefore,  the  DoD  TRM 
was  used  in  evaluating  the  JCALS  program. 

0  Reference  Stage  4.  Software  demonstrations  of  JCALS  were  conducted. 
The  demonstrations  were  used  to  verify  information  obtained  through 
review  of  JCALS  system  documentation  and  to  assist  completion  of  the 
DoD  TRM  matrix  provided  in  appendix  C. 

o  Reference  Stage  5.  The  results  of  each  stage  of  the  evaluation  are 
documented  in  the  appendixes  and  tables  of  this  document 

333  User  Interface  Evalnntlon.  To  support  the  user  interface  evaluation  process,  the 
following  methodology  was  implemented: 

o  Reference  Stage  3.  The  DISA  Center  for  Information  Management  "Tech¬ 
nical  Reference  Model  for  Information  Management"  document  was 
reviewed,  and  applicable  standards  were  extracted  and  included  in  a 
compliance  matrix  checklist  Chapter  10  of  the  DMR,  "Strategies  for  Open 
Systems,"  references  the  OSF  DCE  as  a  standard  to  be  used  for  evaluating 
cUent-server  architectures.  However,  in  the  DoD  community,  the  OSF 
DCE  standard  is  represented  by  the  DoD  TRM.  Therefore,  the  DoD  TRM 
was  used  in  evaluating  the  JCALS  program. 
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I  0  Reference  Stage  4.  The  DoD  "Human  Computer  Interface  (HCI)  Style 

Guide”  was  reviewed  and  user  interface  requirements  were  developed. 
I  These  requirements  were  documented  in  a  DoD  HCI  Style  Guide  compli- 

1  ance  matrix  (see  appendix  D).  A  thorough  and  comprehensive  analysis  of 

JCALS  human-computer  interface  documents  was  then  conducted  to  assess 
I  JCALS  compliance  with  the  requirements  documented  in  the  compliance 

I  matrix. 

I  o  Reference  Stage  5.  A  software  demonstration  of  the  components  of  the 

I  JCALS  program  was  attended.  The  demonstration  was  used  to  verify  infor¬ 

mation  obtained  through  review  of  JCALS  human-computer  interface  docu- 
I  mentation  and  to  assist  completion  of  the  DoD  HCI  Style  Guide  compli- 

I  ance  matrix  provided  in  appendix  D. 

I  0  Reference  Stage  6.  The  results  of  each  stage  of  the  evaluation  were 

I  documented  and  are  included  in  the  appendixes  of  this  document. 
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SECTION  4. 


nNDINGS 


4.1  RCAS  Findings 

After  analyzing  the  results  of  RCAS  evaluation  efforts,  the  following  general  findings  and 
conclusions  were  developed  concerning  the  RCAS  systems  architecture.  Specific  conclusions 
were  developed  for  each  of  the  three  areas  analyzed  during  the  RCAS  evaluation:  client- 
server,  user  interface,  and  RCAS  Economic  Analysis  Report  The  general  findings  and  con¬ 
clusions  on  the  RCAS  systems  architecture  are  provided  below,  and  specific  conclusions  for 
the  functional  areas  analyzed  are  provided  in  &e  following  subsections. 

The  RCAS  systems  architecture  is  a  well-founded  and  comprehensive  open  systems,  stan- 
dards-based  architectural  model.  In  addition  to  rules  and  guidelines,  the  system  architecture 
is  composed  of  the  following  four  key  elements: 

o  Information  Model  (IM):  Defines  the  overall  RCAS  information  structure 
in  terms  of  processes,  information  classes,  and  organizational  use  of 
information.  The  IM  is  used  to  define  the  three  architectural  elements  of 
the  system  architecture. 

o  Data  architecture:  Provides  a  high-level  data  view  used  to  define  data 
sharing  and  distribution  requirements  and  to  support  data  base  design  and 
analysis  efforts,  and  is  used  in  the  formation  of  the  data  dictionary. 

o  Application  architecture:  Provides  guidelines  for  application  development, 
and  identifies  candidate  applications  to  replace  manual  processes  and  appli¬ 
cation  interdependencies. 

0  Geographic/technical  architecture:  Identifies  the  location  or  geographic 
distribution,  communications  connectivity,  and  technical  performance  data 
and  iqTplication  distribution  requirements. 


4.1.1  Client-Server  findings.  The  following  describes  the  RCAS  client-server  system 
and  presents  general  findings  of  the  RCAS  client-server  system. 

4.L1.1  Description  of  the  RCAS  Client-Server  System.  Of  the  five  basic  client-server 
models  delineated  in  section  2,  RCAS  has  components  that  adhere  to  only  the  remote  pre¬ 
sentation  model  as  illustrated  in  table  4-1.  Current^,  no  other  client-server  interfaces  exist 
for  the  RCAS  servers  (Zenith  486  platforms)  nor  are  there  plans  to  implement  such  an 
architecture  in  the  near  future,  although  the  current  and  future  hardware  (DEC  RISC 
servers)  and  software  will  support  a  client-server  configuration. 
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Table  4-1.  RCAS  Client-Server  Environment 


COfJtf«C?;EMT3 

SDAS  CUE.*IT 

RCAS  SERVER 

Hardware 

Human  Design  System  (HDS) 

X  Station 

486  Server 

DEC  System  5000/200 

DEC  System  5500 

Software 

X  Windows  Olent 

OSF/MOTIF  GUI 

OA  Server 

Application  Server 

A  UNIX  pipes  EPC  interface  to  the  Data  Object  Manager  (DOM)  exists,  which  communi¬ 
cates  to  the  Data  Synchronization  Manager  (DSM)  through  a  pipes  interface.  This  IPC 
between  the  DOM,  DSM,  and  the  rest  of  RCAS  is  an  example  of  a  client-server  architecture 
where  both  client  and  server  are  on  the  same  computer. 

Utility-type  client-server  processes  also  exist  that  are  transparent  to  the  end  user  and  thus 
are  not  traditional  client-server  applications.  These  applications  (e.g.,  MaxSix,  Secure  X 
windows)  primarily  deal  with  trusted  labeling  and  other  security  features. 

4.1.1J2  Findings.  It  may  be  benefidal  to  investigate  using  Control  and  Analysis  Tool 
(CAT)  Project  Manager  as  a  front-end  interface.  This  tool  has  a  4GL,  supports  SQL,  and 
could  be  combined  with  an  SQL  engine  such  as  INFORMIX  on  a  separate  platform.  Other 
front  ends,  such  as  INFORMIX  SQL  4.1,  and  X  Windows-compliant  front  ends  with  an 
INFORMDC  API  also  should  be  considered. 

Currently,  the  X  Server  is  downloaded  to  each  client  machine  at  bootup.  If  client  work¬ 
station  random  access  memory  (RAM)  becomes  scarce,  it  may  be  more  beneficial  to  con¬ 
sider  a  remote  invocation  of  the  X  Server  from  the  client.  This  would  result  in  the 
distributed  presentation  client-server  model. 

Any  baseline  distributed  client-server  technical  approach  should  consider  implementing  the 
following: 

o  A  distributed  COTS  SQL-compliant  and  RDA-compliant  relational  DBMS. 
Such  a  DBMS  should  be  supported,  although  contractor-developed  software 
may  suffice  (e.g.,  JCALS  GDMS).  Support  for  and  enhancements  to  the 
DBMS  should  be  included  in  the  procurement. 

A  POSIX-compliant  (preferably  UNIX)  operating  system.  UNIX  is  the  tfe 
facto  standard  in  open  operating  systems  and  it  easily  supports  the  client- 
server  paradigm  with  its  sockets  IPC.  In  addition,  many  versions  are 
POSIX-compliant. 


o 


o 


A  client-server  IPC  that  implements  an  RPC  or  Berkeley  Sockets.  The 
concept  of  an  RPC  is  developing.  The  idea  behind  a  remote  procedure  call 
is  to  mimic  local  appli  ..ation  development  while  transparently  using  the  low- 
level  IPC  to  communicate  to  remote  procedures.  Using  l^C  instead  of 
writing  low-level  IPCs  such  as  sockets  could  save  a  tremendotis  amount  of 
development  time. 

o  A  user  interface  that  implements  X  Window  with  MOTIF  or  OPEN  LOOK. 
The  X  Window/MOTIF  user  interface  has  been  demonstrated  in  RCAS 
and  JCALS.  Both  use  Ada  language  binding,  and  communicate  through 
Pipes  (RCAS)  or  Sockets  (JCALS)  to  server  applications. 

o  Source  code  written  in  Ada.  Ada  is  a  demonstrated  robust  language  and 
handles  client-server  communications  adequately.  This  was  shown  in  the 
Data  Object  Module  and  Data  Synchronization  Module  of  RCAS  and  the 
Global  Data  Management  System  (GDMS)  of  JCALS. 

The  open  systems,  standards-based  RCAS  ^tems  architecture,  AIS  platforms,  and  telecom¬ 
munications  system  are  fully  capable  of  hnusing/sup^rting  client-server  applications. 

4.12  User  Interface  Findings.  The  following  subsections  describe  the  user  interface 
^tem  implemented  in  RCAS  and  present  a  summary  U  Snuings.  Most  of  the  findings 
regarding  the  RCAS  user  interface  are  based  on  the  review  of  the  results  of  RCAS 
compliance  with  the  DoD  HCI  Style  Guide.  These  results  are  shown  in  appendbc  B.  Addi- 
tionid  conclusions  were  developed  as  a  result  of  the  RCAS  demonstration  provided  by  the 
Boeing  Company  on  21  September  1992. 

4.i:Z.l  Description  of  the  User  Interface  System.  The  RCAS  GUI  is  based  on  the  X 
Window  System  (XI 1  Rel  4)  and  the  OSF/MOTIF  Graphical  User  Interface  (Rel  1.1.1). 
The  GUI  is  an  integral  part  of  the  user’s  view  of  the  RCAS  and  alleviates  the  need  for  each 
user  to  become  proficient  in  the  use  of  the  operating  system.  Tlie  Open  Desktop  GUI, 
which  RCAS  uses,  includes  the  Desktop  Manager,  X  Window  System,  and  the  MOTIF 
Window  Manager. 

The  Desktop  Manager  insulates  the  user  from  the  technical  complexities  of  the  operating 
^tem,  and  provides  a  see-and-point  user  interface.  The  desktop  is  a  window  populated 
with  icons.  The  icons  are  graphic  representations  of  applications  or  processes.  The  X 
Window  system  provides  for  the  development  of  portable  GUIs. 

Windows  can  be  displayed  on  zny  hardware  device  that  supports  the  X  protocol.  The 
MOTIF  Window  Manager  provides  session  and  window  management  capabilities.  It  creates 
the  border  that  forms  around  every  Open  Desktop  Window,  enabling  the  window  to  be 
moved,  resized,  overlapped,  shuffied,  and  reduced  to  an  icon  within  the  desktop. 
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The  office  automation  environment  of  the  RCAS  is  provided  through  the  use  of  UNIPLEX 
CXDTS  software.  UNIPLEX  Windows  provides  the  capability  to  run  the  UNIPLEX  applica¬ 
tions  under  the  Desktop  Manager  and  X  Window  components  environment 

The  GUI  utilities  are  designed  as  trusted  applications  using  Ada.  The  GUI  utilities  consist 
of  the  Window  Object  Manager  (WOM),  the  Navigation  Application  Broker  (NAVAB),  and 
Help. 

The  WOM  provides  a  consistent  user  interface  throughout  the  RCAS.  It  is  a  generalized 
GUI  and  presentation  manager  engine.  It  performs  presentation  management  functions  on 
behalf  of  the  application  (client)  program  ^  using  X  Window  and  MOTIF  products  to  con¬ 
struct  dialogues  with  the  users.  The  WOM  is  started  by  the  RCAS  desktop  and  is  respon¬ 
sible  for  interaction  with  the  POSIX-compliant  operating  system  processes.  The  WOM 
interprets  interprocess  communication  data  received  from  client,  detects  either  presen¬ 
tation  (display)  or  dialogue  (data  entry)  requests,  retrieves  ap^''opriate  information,  and 
applies  them  to  the  user’s  video  display  terminal  (VDT).  The  WOM  also  nutifres  the  user 
of  ^tem  activity  if  responses  are  not  received  within  15  seconds  of  a  user-initiated  action. 
During  dialogue  management,  the  WOM  provides  the  primary  data  validation  mechanism 
for  data  entering  the  RCAS.  The  WOM  directs  the  MOTIF  Window  Manager  to  allow 
input  of  only  certain  characters.  The  WOM  also  provides  user  access  to  Help. 

The  NAVAB  provides  the  user  with  generalized  access  to  RCAS  application  functions.  It 
provides  the  capabili^  to  request  blank  forms,  allows  for  quicker  access  to  applications  by 
maintaining  a  log  of  applications  executed  by  the  user,  and  provides  a  standardized 
functional  process  to  select  a  particular  application  for  execution.  The  NAVAB  interfaces 
through  the  WOM  to  provide  the  necessaiy  menus  needed  to  navigate  the  RCAS. 

The  Help  utility  provides  the  user  with  assistance  on  the  use  of  RCAS  applications.  The 
Help  fimctionali^  is  bundled  into  the  WOM.  Two  types  of  Help  are  available  to  the  RCAS 
user  general  subject/topical  and  field  definitions/descriptions. 

4.UJ2  Findings.  RCAS  had  over  a  90  percent  compliance  rate  for  user  interface  require¬ 
ments  where  sufficient  information  was  available  to  make  an  assessment 

The  RCAS  user  interface  is  based  on  an  OSF/MOTIF  approach.  DoD  HQ  Style  Guide 
requirements  addressing  an  OPEN  LOOK  approach  to  a  user  interface  were  determined  to 
not  be  applicable  when  evaluating  the  RCAS  program. 

RCAS  uses  a  forms-based  approach  for  electronic  processing  of  government  standard  forms. 
RCAS  philosophy  is  that  this  approach  minimizes  training  in  the  user  environment  This 
forms-based  approach  may  be  applicable  in  other  frmctional  areas  where  there  is  a  need  for 
automated  processing  of  standard  forms. 
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RCAS  uses  Ada  as  the  application  development  language.  Since  Ada  is  a  CIM  standard, 
porting  the  RCAS  Ada  c^e  should  not  pose  serious  problems. 

4.13  RCAS  Economic  Analysis.  The  savings  identified  in  the  RCAS  BA  are  based 
primarily  on  cost  avoidance  and  cost  savings  accrued  through  improved  efficiencies  in 
processing,  staffing,  copying,  and  transmitting  forms.  This  is  supported  by  the  basic  RCAS 
tq)plication  user  interface,  which  is  an  on-screen  graphic  representation  of  the  form  on  which 
the  soldier,  requiring  little  or  no  training  or  interpretation,  enters  the  information. 

In  calculating  the  cost  avoidance  and  cost  savings  in  the  RCAS  BA,  it  was  determined  that 
the  efficiencies  should  be  "time-streamed"  according  to  the  fielding  plans.  This  was  reflected 
in  the  benefits-by-year  tables  and  reflected  a  payback  on  the  project  no  later  than  FY  95. 
Additionally,  the  first  month  after  installation  of  RCAS  in  a  unit,  it  was  assumed  that  no 
benefit  wo^d  accrue  to  the  unit  during  the  learning  and  familiarization  period.  This 
ensured  a  conservative  estimate  of  benefits. 

For  applications  whose  functional  requirements  closely  match  those  of  the  RCAS,  similar 
savings  levels  per  unit  of  work  should  be  seen.  As  applications’  functional  requirements 
deviate  from  those  of  the  RCAS,  the  RCAS  BA  model  becomes  unusable.  For  applications 
that  do  not  closely  match  RCAS  functions,  a  detailed  risk-adjusted  Functional  Economic 
Analysis  would  be  necessary  to  quantify  benefits. 

43  JCALS  nndln^ 

After  analyzing  the  results  of  JCALS  evaluation  efforts,  the  following  general  findings  and 
conclusions  were  developed  concerning  the  JCALS  systems  architecture.  The  general  find¬ 
ings  and  conclusions  on  the  JCALS  systems  architecture  are  provided  below,  and  specific 
conclusions  for  the  fimctioiuil  areas  analyzed  are  provided  in  the  following  subsections. 

The  JCALS  systems  architecture  is  a  well-founded  and  comprehensive  open  systems, 
standards-based  architectural  model.  In  addition  to  rules  and  guidelines,  the  systems 
architecture  is  composed  of  the  following  key  subsystems: 

o  Network.  The  network  subsystem  is  a  three-tiered  structure  that  involves 
regional,  organizational,  and  user  functions.  Regional  network  processing 
involves  monitoring  and  evaluating  the  entire  JCALS  network.  The  organ¬ 
ization  tier  involves,  among  other  functions,  connecting  LANs  and  WANs. 
The  user  tier  deals  with  user-level  functions,  which  connect,  retrieve,  and 
process  information  off  the  network. 
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o  Workstation  Servers.  Workstation  servers  contain  the  JCALS  executable 
modules,  which  may  be  replicated  and  distributed  among  several  servers. 

o  Data  Management  Processor.  The  DMP  server  contains  the  DBMS  COTS 
^tem  software,  which  interoperates  with  the  Global  Data  Base  Manage¬ 
ment  System  (GDMS). 

o  Workstation  Clients.  The  workstation  clients  are  the  GDMS  client  and  the 
user  interface  client 

A2,l  Client-Server  Findings.  The  following  JCALS  findings  are  relative  to  its  client- 
server  architecture 

The  main  dient-server  component  of  JCALS  is  the  GDMS,  which  comprises  three 
subcomponents: 

o  Global  Transaction  Management  System  (GTMS) 
o  Global  Data  Dictionary  System  (GDDS) 
o  Local  Data  Management  System  (LDMS). 

These  subcomponents  are  hosted  on  the  Data  Management  Processor,  and  the  various 
JCALS  client  processes  run  on  client  workstations.  The  components  of  the  GDMS  act  as 
both  clients  and  servers  to  one  another  but  as  servers  to  the  workstation  client  processes. 
Clients  and  servers  communicate  through  the  UNIX  domain  sockets. 

The  LDMS  coordinates  all  requirements  for  local  processor  services.  It  provides  data 
management  services  support  for  accessing  local  Relational  Data  Base  Management  Systems 
(RDMSs),  text  data  bases,  UNIX  data  bases,  and  some  "C  interface  routines. 

Ihe  GDMS  will  bridge  local  and  remote  sites.  Once  the  GDMS  server  is  activated,  it 
accepts  socket  connections  from  client  applications  and  other  GDMS  servers/clients.  Each 
socket  connection  is  either  a  local  request  or  a  remote  transaction  request  The  GDMS  will 
queiy  the  GDDS  module  for  location  information,  priorities,  data  triggers,  constraints,  and 
security  information.  Once  the  source/destination  of  the  data  is  located,  GDMS 
transactions  are  created,  scheduled,  and  dispatched  to  either  the  LDMS  running  locally  or 
to  other  GDMS  sei  vers/clients  executing  at  remote  sites. 

GDMS  provides  for  data  integrity  via  a  Global  Data  Integrity  component,  which  includes 
two-phaM  commit  logic.  The  two-phase  commit  process  involves  determining  if  requested 
data  elements  are  currently  being  used  (Phase  1)  and,  if  not,  locking  those  elements  and 
committing  the  update  (Phase  2).  The  GDMS,  together  with  the  LDMS,  returns  data  to  the 
requesting  client  applications  though  a  front-end  X  Windows/MOUF  GUI. 


These  findings  are  ^opsized  below: 

o  The  user  interface  application  is  based  on  X  Windows/MOTIF. 

o  The  basic  architecture  of  the  JCALS  data/appb'otion  system  is  based  on 
the  client-server  paradigm  (with  GDMS  compo  smts  acting  primarily  as 
servers)  using  a  UNIX  sockets  IPC 

o  Both  CX)TS  and  non-COTS  components  make  up  the  data  system,  with  the 
non-COTS  GDMS  acting  as  a  distributed  DBMS. 

o  The  COTS  SQUcompliant  RDBMS  and  the  operating  system  employed  are 
Bl-certified.  The  operating  intern  is  POSIX-compliant,  and  most  of  the 
code  is  written  in  Ada,  which  is  consistent  with  portability  requirements  of 
the  CIM  Directive. 

o  JCALS  will  interconnect  to  245  JCALS  sites. 

o  Each  JCALS  site  has  a  data  system  consisting  of  RDBMS,  UNIX  system 
files,  and  a  text  DBMS. 

4JL2  User  Interface  Findings.  Most  of  the  conclusions  regarding  the  JCALS  user  inter¬ 
face  methodology  are  based  on  the  review  of  the  results  of  JCALS’  compliance  with  the 
DoD  HQ  Style  Guide  and  adherence  to  the  DoD  TRM.  These  results  are  shown  in 
appendix  D  of  this  report  The  following  additional  conclusions  were  developed  as  a  result 
of  the  JCALS  demonstration  in  November  1992: 

o  JCALS  had  over  a  90  percent  compliance  rate  for  user  interface  require¬ 
ments  where  sufficient  information  was  available  to  make  an  assessment 

o  The  JCALS  user  interface  is  based  on  an  OSF/MOTIF  approach. 

DoD  HQ  Style  Guide  requirements  addressing  an  OPEN  LOOK  approach 
to  a  user  interface  were  determined  to  not  be  applicable  when  evaluating 
the  JCALS  program. 
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